In telecommunications networks such as GSM (Group System for Mobile Communication) and UMTS (Universal Mobile Telecommunication System) and UTRAN (Universal Telecommunication Radio Access Network), in which WCDMA (Wideband Code Division Multiple Access) is one radio transmission method, the transferred data, e. g. speech data, is compressed before it is transported over the radio interface. This reduces the bandwidth demands on the scarce resource radio interface. To achieve this compression, codecs (coder and decoder algorithms as well as a means provided for performing that algorithm) are used. The term codec can be replaced by the term “coding scheme” which has the same meaning. In many networks different codecs can be used and different nodes can have different capabilities for handling codecs. When conversion from one coding scheme to another takes place, the process is called transcoding. Transcoding anywhere in the speech path negatively affects data quality. The number of transcoding stages in the speech path has to be minimized in order to maximize data quality. In the following data quality in the meaning of this application is the quality of audio or video data.
Determination of an optimal codec may be done by means of Codec Negotiation. 3GPP standard TS 23.153 specifies an Out of Band Transcoder Control (OoBTC) procedure which is the capability of a network to negotiate the types of codec and codec modes on a call per call basis with out-of-band signalling procedures. These procedures are specified to take place in the call setup phase or possibly later if there is a need to re-negotiate the codec. OoBTC is performed between serving core network nodes or control nodes taking into account transcoding capabilities of all involved parties, including the user equipment (UE), the radio network nodes and the Media Gateway (MGW) nodes under the control of their serving or control nodes. Ideally the same codec is used in the whole connection between the access networks. This well known codec negotiation mechanism is only based on the capability of involved parties.
FIG. 1 shows a simplified dataflow diagram which depicts the message flow in a negotiation procedure of coding schemes or codecs between control nodes of a telecommunication network. An initiating node 11 initiating codec negotiation creates a codec list containing a list of all codecs supported by a payload node which is under control of the initiating node. The so called supported codec list (SCL) is forwarded in a Bearer Independent Call Control (BICC) Initial Address Message (IAM) 14 to the terminating control node 13. Any intermediate control node 12 evaluates the SCL and removes non-supported codecs from the SCL. An intermediate node 12 can not add new codecs which e.g. are supported in addition by the intermediate node 12. The SCL is further forwarded 15 to the terminating control node 13. The terminating control node 13, which terminates the codec negotiation, evaluates the SCL, removes non-supported codecs from the SCL and selects the most appropriate codec for the call from the remaining codecs in the SCL. The selected codec (SC) and the available codec list (ACL) which is a copy of the final SCL after the terminating control node 13 has removed non-supported codecs from the SCL are sent backwards via a BICC application transport mechanism (APM) message 16 and 17 to the initiating control node 11. The initiating node 11, the intermediate node 12 and the terminating node 13 setup their payload nodes to use the selected codec which was indicated in the APM BICC message 16, 17.
FIG. 2 shows a circuit switched communication network comprising MSC Server 23, 24 as control nodes. Every MSC Server 23, 24 is in control of a payload node or media gateway node MGW 27, 28. Further an originating mobile equipment or subscriber MS 21 is connected via a base station controller BSC 22 to the MGW 27 and is further connected to the MSC Server 23. A terminating MS 26 is connected via the terminating BSC 25 to the terminating MGW 28 and to the terminating MSC Server 24. Between the originating side and the terminating side of the network a transit network is located which may comprise further control nodes and/or payload nodes. The payload is routed over the MGWs 27, 28 between the mobile terminals or equipments 21, 26 in the User Plane. The control data is routed over the MSC Server 23, 24 in the Control Plane. The codec negotiation takes place between the MSs 21, 26 and the MSC Server 23, 24. The MSC Server 23, 24 are in control of their MGW 27, 28 via MGW Control messages and of the BSC 22, 25 via BSSAP messages. After codec negotiation has been established the MSC Server 23, 24 will instruct the MGWs 27, 28 and the BSCs 22, 25 to use at least one specific codec.
A more complex dataflow diagram of a state-of-the-art codec negotiation is shown in FIG. 3. At a call setup in an AoIP-scenario (interface user plane over IP), the originating call control node 33, which is depicted as an originating mobile switching center (oMSC) but which can be any kind of control node controlling a connection in a telecommunication network, receives 301 a list of codecs which are supported by an originating radio network control node 32. In case of an interface over TDM scenario the oMSC 33 configures the codec for the oBSC 32. This radio network control node 32 is pictured as a base station controller node of a GSM network but can be any kind of radio network control node. This supported codec list of the originating base station subsystem (oBSS-SCL) is sent to the oMSC 33 via a Complete Layer 3 (CL3) message 301. The CM Service Request message is contained within the Complete Layer 3 (CL3) message. The originating call control node 33 further receives via a setup message 302 a list of supported codecs of the originating mobile subscriber 31 (oMS-SCL). An example for GSM codecs are:                GSM_HR;        GSM_FR;        GSM_EFR;        HR-AMR(set 1);        FR-AMR(set 1);        FR-AMR-WB(set 0).        
FR-AMR-WB(set 0), FR-AMR(set 1), GSM_EFR and GSM_FR are full rate codecs. The codecs HR-AMR(set 1) and GSM_HR are half rate codecs. Half rate codec requires half the bandwidth of the full rate codec. Usage of half rate codecs allows the operator to handle more calls since they use less bandwidth. At the same time, usage of half rate codecs results in lower speech quality. Normally the codecs will be prioritized, to be included in an originating supported codec list (oSCL), in the order FR-AMR-WB(set 0), FR-AMR(set 1), GSM_EFR, HR_AMR(set 1), GSM_FR and GSM_HR. This order is determined on operator preference for codecs to be used for speech calls and based on the speech quality to be achieved using the codecs in transcoder free situations.
The setup message 302 further comprises a radio channel property (oRCP) as preferred by the originating subscriber 31. The oRCP indicates the type of radio channels selected and is used by the oMSC 33 to select the codec for the originating radio call leg between the oMS 31 and the oMSC 33. At first assignment the selection of the traffic channel to be used by the oBSC 32 is based on the preference of the mobile subscriber 31, the preference for each basic service or operator and the capacity of the oBSC 32. The oRCP is received from the oMS 31 and possibly modified by the Telecommunication Service Analysis in order to take operator's preference for channel rate and type into consideration. For speech calls, RCP can include following values as example:                Half Rate (HR) channel required;        Full Rate (FR) channel required;        HR or FR channel required, HR channel preferred;        HR or FR channel required, FR channel preferred;        HR or FR channel required, no preference.        
After the oMSC 33 sends a Call Proceeding message 303 to the oMS 31, an IAM message 304 is sent to the terminating control node tMSC 34. This message comprises an originating supported codec list (oSCL), which was built in the oMSC 33 by using the oMS-SCL, the oBSS-SCL and the capacity of the controlled, but not shown originating media gateway node (oMGW) which is under control of the oMSC 33. FIG. 3 does not disclose any intermediate node due to illustration reason. If there are intermediate nodes between the oMSC 33 and the tMSC 34, these nodes will remove any non-supported codecs, which are not supported by the intermediate payload nodes under control of the intermediate control nodes from the oSCL and forward the oSCL to the next intermediate control node or to the terminating control node tMSC 34.
After the tMSC 34 receives the oSCL in the IAM 304 it removes all codecs which are not supported in the terminating MGW. After a paging procedure 305 took place, executed by the tMSC 34 to find the allocated terminating mobile subscriber (tMS) 36, a CL3 message 306 containing paging response is sent from the terminating base station controller tBSC 35, which is in control of the tMS 36, to the tMSC 34. This message 306 comprises a supported codec list of the terminating Base Station Subsystem (tBSS). After the tMSC 34 sends a Setup message 307 to the tMS 36, the tMS 36 sends a Call Confirmed message 308 including a supported codec list (tMS-SCL) and the radio channel property of the terminating mobile station (tRCP) to the tMSC 34. The tRCP is used by the tMSC 34 to select the codec for the terminating radio call leg.
The tMSC 34 creates a terminating SCL taking into consideration the tMS-SCL, tBSS-SCL and the tMSC-SCL. The terminating MSC 34 then selects a selected codec (SC) which is best suited for this call. The SC is selected based on the oSCL that has been received and from which all non-supported codecs are removed. Possibly the tMSC-SCL is also considered when establishing the SC. From the perspective of the tMSC 34 the SC is the best codec suited for the call as a compromise between speech quality and bandwidth usage. The SC is supported by all MGWs which are involved in this call (for transporting the payload information of the call in the core network) such that the best call quality and/or bandwidth usage is reached. Further the tMSC 34 creates an available codec list (ACL) which comprises all codecs of the oSCL after the tMSC 34 removed the non-supported codecs from this list.
The ACL is the list of all codecs which are supported in the payload nodes (MGWs) of the core network. This list contains all codecs which are supported in all nodes involved in the codec negotiation for the call. The ACL and the SC are sent in an APM (Application transport message) 309 to the oMSC 33. All possible intermediate control nodes and the originating control node 33, which receive the APM 309 comprising the ACL and the SC, will setup their controlled media gateways to establish the SC for this specific call to use the codec specified by the SC.
After the oMSC 33 received the APM 309, an Assignment Request message 310 is sent to the oBSC 32 containing a list of codecs in preferred order by taking into consideration SC as well as oRCP. The oBSC 32 answers with an Assignment Complete message 311 containing the codec that is used for the call on the originating radio access. After the oMSC 33 receives the Assignment Complete message 311, it sends an APM message to the terminating MSC 34 which also sends an Assignment Request message 313 to the tBSC 35. The Assignment Request message 313 contains a list of codecs in preferred order by taking into consideration the SC as well as the tRCP. The tBSC 35 sends back an Assignment Complete message 314 to the tMSC 314 containing the codec list that is used for the call on the terminating radio access. After the tMSC 314 receives the Assignment Complete message the negotiation process is completed.
If the originating or the terminating radio call leg has to use a codec, based on the oRCP and the tRCP, which might be different to the selected codec SC of the core network, a codec transcoding has to be performed in the originating and/or the terminating control node. This can result in a lower speech quality as well as increasing resource usage because every transcoding procedure reduces the data quality and requires higher processing need.
As an example for a codec negotiation according to the state of art it is assumed that the oMS 31 supports the codecs {GSM_HR, GSM_FR, GSM_EFR}. It is further assumed that the oRCP of the mobile subscriber which is allocated to the oMS 31 indicates that it supports both halfrate radio channel (HR) and fullrate radio channel (FR), but prefers HR. Further the oBSC 32 supports {GSM_EFR, GSM_FR, GSM_HR} and the core network supports {GSM_EFR, GSM_FR, GSM_HR, PCM}. The originating MSC 33 will generates an oSCL as {GSM_EFR, GSM_FR, GSM_HR, PCM} and will send it in a BICC IAM message 304 to the terminating control node tMSC 34. It is assumed that the tMS 36 supports codecs {GSM_HR, GSM_FR, GSM_EFR} and the tRCP indicates that it supports both HR and FR channels, but prefers HR. Further the tBSS-SCL should looks like {GSM_HR, GSM_FR, GSM_EFR} and the core network on the terminating side supports {GSM_EFR, GSM_FR, GSM_HR, PCM}. The tMSC 34 chooses the codec GSM_EFR as the selected codec (SC) which will be used by the media gateways in the core network. This codec will be sent as the selected codec (SC) to the oMSC 33. If an intermediate node is arranged between the oMSC 33 and the tMSC 34, it will setup the intermediate MGW to use the selected codec GSM_EFR.
Due to the fact that the RCP on both sides prefers HR, the communication leg between the originating MGW and the originating MS 31 will be defined as GSM_HR. The same occurs on the terminating side. As a result, a transcoding between the codec GSM_EFR and the codec GSM_HR will take place in both the originating MGW and the terminating MGW. This results in unnecessary usage of valuable transcoder resources and a reduction of data quality.